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REMARKS 

The office action mailed March 21, 2006 has been carefully considered and these remarks 
are responsive thereto. Prior to entry of the amendments herein, claims 1-44 are pending and 
stand rejected. Applicants herein amend claims 1, 7, 8, 11-13, 17, 23, 29, 30, 33-35 and 39 and 
cancel claims 6 and 28. No new matter has been added. 

Applicants amend the specification to supply a serial number for a U.S. Patent 

application and to correct an obvious grammatical error. 

The office action rejected independent claim 1 and claims 5, 6 and 8-12 depending 

therefrom under 35 U.S.C. § 102(b) based on U.S. Patent 5,675,329 (Barker et al., hereinafter 

"Barker"). Barker fails to teach all features of claim 1, which Applicants herein amend to 

include the features of claim 6. In particular, claim 1 recites a step of automatically generating, 

at a repeat rate based on key force data for a key held pressed by a user , a third type keyboard 

data message indicating the held key has been pressed (emphasis added). The office action 

asserts the following with regard to this feature at pages 3-4: 

As for claims 6, 8, 28, 30, Barker teaches of automatically generating, at a repeat 
rate based on key force data for a key held pressed by a user, a third type 
keyboard data message (180) indicating the held key has been pressed {claims 6, 
28} and that the method of claim 6, wherein the automatically generating a third 
type keyboard data message comprises mapping a repeat rate to the key force data 
for the held key {claims 8, 30} in Fig. 2 and in column 4, lines 1 12-22 [sic]. One 
can see from the figure that the diagram cycles through, hence has a repeated rate. 

Notably, the office action relies on the flow chart of Barker figure 2, reproduced below 
for convenience: 
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The office action appears to argue that loops through this flow chart for a key that has 
already been pressed correspond to the repeat rate that is now recited in claim 1 . Even if this is 
true, however, the office action does not explain how the rate of such loops through the flow 
chart algorithm, for a key held pressed by a user, is based on key force data for that key that is 
being held pressed . In other words, the office action does not explain how the algorithm would 
go from block 160 (or block 170) to block 180 at a faster or slower rate based on how much 
force is being applied to a key. Neither Barker figure 2 nor the portion of the Barker 
specification cited by the office action provide any hint of such a feature. Barker col. 4, lines 17- 
22 merely state that: 

If a new key has not been pressed, i.e., a key that has already been pressed has 
been pressed again, the process returns to step 140 to repeat the process of 
determining whether a force greater than the second actuating force has been 
applied. In this manner, steps 110, 120, 130, 140, and 150 and 160 or 170 may be 
repeated for each key of the keyboard 1 1 . 
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Neither the above passage nor any other part of Barker suggests that the rate at which steps in 
figure 2 are repeated is in any way affected by key force data for a key held pressed. For 
example, Barker does not suggest that a key held pressed with less than a "normal" force causes 
the algorithm to repeat at a rate different from the rate at which the algorithm would repeat for a 
key held pressed with "> the second activating force." 

Because Barker fails to teach all features of claim 1, claim 1 is allowable. Claims 5 and 
8-12 depend from claim 1 and are allowable for the same reason as claim 1, and further in view 
of additional features recited therein. For example, claim 5 recites that receiving keyboard data 
sets comprises receiving a data set having key identification data and key force data for multiple 
keys. The office action appears to assert that this taught by Barker figure 2 and by Barker 
"column 3, lines 50-20." Office action at page 3. However, Barker does not teach receiving a 
data set with key identification and key force data for multiple keys. Instead, Barker teaches that 
key data is received for one key at a time. 

Claim 1 1 recites a transfer function that comprises an initial group of sub-ranges mapped 

to gradually increasing repeat rate values followed by a group of sub-ranges mapped to sharply 

increasing repeat rate values. There is no mention whatsoever in Barker of such a transfer 

function. The office action asserts at page 4 that 

As for claims 1 1, 33, Barker teaches that the transfer function comprises an initial 
group of sub-ranges mapped to a gradually increasing repeat rate values followed 
by a group of sub-ranges mapped to a sharply increasing repeat rate values in 
column 3, lines 1-20. The force that the user exerts in pressing the buttons 
gradually increases in order to reach the second function of that particular button. 

Aside from the fact that the cited portion of Barker says nothing with regard to a user- 
exerted button force "gradually" increasing, the office action fails to address all features of claim 
11. Specifically, claim 11 requires that there be an initial group of sub-ranges mapped to 
gradually increasing repeat rate values and that there also be a group of sub-ranges mapped to 
sharply increasing repeat rate values . In other words, there must be at least four sub-ranges of 
force data values, with each of those sub-ranges mapped to separate repeat rate values. There is 
nothing in Barker that even remotely suggests such a feature. 
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Claim 12 recites determining if a repeat invoke delay has elapsed since the user initially 
pressed the held key, as well as commencing said automatic generation after the repeat invoke 
delay has elapsed. The office action appears to argue at page 5 that the time needed to repeat a 
cycle of the Barker figure 2 algorithm corresponds to the recited invoke delay. However, Barker 
does not teach or suggest that there is any relationship between that cycle time and the time since 
a key was initially pressed. 

The office action rejected claims 2-4, 7 and 13 under 35 U.S.C. § 103 based on Barker. 
These claims also depend from claim 1, and therefore lack the above described feature of claim 1 
not taught or suggested by Barker. Accordingly, claims 2-4, 7 and 13 are also allowable. 

The office action rejected independent claim 14 under 35 U.S.C. § 102(b) based on 
Barker. Similar to claim 5, however, claim 14 recites receiving a keyboard data set reporting, for 
multiple keys of the plurality [of keys] pressed by a keyboard user, key force data and key 
identification data. Claim 14 is thus allowable for the same reason as claim 5. The office action 
rejected claims 15 and 16 under 35 U.S.C. § 103 based on Barker. These claims depend from 
claim 14, and are therefore also allowable. 

The office action rejected independent claims 17-22 under 35 U.S.C. § 103 based on 
Barker. Claim 17 as amended recites, inter alia, receiving a registration from a first application 
program requesting keyboard input data and key force data, and receiving a registration from a 
second application program requesting keyboard input data but not requesting key force data. 
Barker does not teach or suggest these features. Notably, Barker does not contemplate the 
presence of applications that process key force data. Instead, Barker appears to assume that the 
operations carried out in connection with Barker figure 2 convert key force data into a format 
understood by all applications. Barker col. 3, lines 5-28 and 42-44 suggest that the algorithm of 
Barker figure 2 is performed by a microcontroller 18 within a keyboard, with that 
microcontroller deciding which key scan code is to be sent (by that same microcontroller) to a 
"system unit 24 of a computer such that the computer is instructed to perform" a corresponding 
function. 
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Barker does not describe sending the key force values to a computer, with applications 
within the computer then deciding how to interpret the key force values. Because of this, and 
because the meaning of a force value is determined within the keyboard before providing a key 
scan code to a computer, there is no need for an application to register and request key force 
data. Barker therefore fails to teach or suggest one application registering and requesting key 
force data and another application registering and not requesting key force data. Accordingly, 
and for at least this reason, claim 17 is allowable. 

Claims 18-22 depend from claim 17 and are allowable for at least the same reason as 
claim 17, and further in view of additional features recited therein. For example, claim 21 recites 
storing the identifier for the last key identified as pressed, storing the most recently received 
force value for the last key identified as pressed, receiving a keyboard data message lacking a 
force value and indicating that the last key identified as pressed remains pressed, and generating 
a keyboard input message identifying the last key identified as pressed and containing the stored 
force value. Nowhere does Barker teach or suggest receiving a data message lacking a force 
value and indicating that the last key identified as pressed remains pressed, and then generating a 
keyboard input message identifying that same key (i.e., the last key identified as pressed) and 
containing the stored force value. Claim 22 recites receiving a simulated keyboard data message 
containing simulated key press data, the simulated key press data identifying an unpressed key 
and containing simulated key force data for the unpressed key, as well as generating a third 
keyboard input message identifying the unpressed key, indicating a simulated key press, and 
containing the simulated key force value. Barker does even hint at generating a message 
regarding an unpressed key that indicates a simulated key press. 

The office action rejected claims 23, 27, 28, 30-34 and 36 under 35 U.S.C. § 102(b) 
based on Barker. The office action further rejected claims 24-26, 29, 35 and 37-44 under U.S.C. 
§ 103 based on Barker. Claims 23 and 39 have been amended in a manner similar to claims 1 
and 17. Claims 23-27 and 29-44 recite a computer-readable medium having instructions for 
performing methods similar to those recited by claims 1-5 and 7-22, respectively, and are 
allowable for the same reasons as claims 1-5 and 7-22. 
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It is respectfully submitted that this application is now in condition for allowance. 
Should the Examiner believe that anything further is desirable in order to place the application in 
even better form for allowance, the Examiner is respectfully invited to contact Applicants' 
undersigned representative at the below-listed number. 

Respectfully Submitted, 



By . /H. Wayne Porter/ 

H. Wayne Porter 
Registration No. 42,084 

BANNER & WITCOFF, LTD. 
1001 G Street, N.W., 1 1th Floor 
Washington, D.C. 20001 
Office: (202) 824-3000 

Dated: June 21, 2006 
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